Summary

Addresses two of the Consecutive HTTP performance issues reported in Sentry for the cli project by caching slug→ID and id→org mappings so repeat invocations skip redundant sequential API calls:

• Pattern C (CLI-1BK) — sentry issue list <org>/<project> used to fire a preflight GET /projects/{org}/{project}/ before every GET /issues/. Now skipped when the project is already in project_cache (populated by listProjects(), DSN resolution, and — new in this PR — by fetchProjectId itself).
• Pattern D (partial, related to CLI-19S / CLI-19W) — sentry issue view <numeric-id> without org context used to fall back to the legacy unscoped /issues/{id}/ endpoint on every run. A new issue_org_cache SQLite table (schema v15) maps numeric-issue-id → org-slug so repeat runs go straight to the regional org-scoped endpoint.

Other Consecutive HTTP issues reported against this project are strict data dependencies (e.g. trace_id lives inside the event body, so /trace/ cannot fire before /events/latest/) or cursor-based pagination the API cannot serve in parallel. Those were triaged and archived in Sentry.

Changes

Pattern C — fetchProjectId cache-first

• src/lib/db/project-cache.ts — new getCachedProjectBySlug(orgSlug, projectSlug) that looks up the most-recent entry across all three existing project_cache key shapes (orgId:projectId, dsn:publicKey, list:{org}/{project}) via MAX(cached_at).
• src/lib/resolve-target.ts — fetchProjectId now:
  1. Consults the cache before calling GET /api/0/projects/{org}/{project}/.
  2. On API success, writes the response back to the cache so the next call skips the round trip. Guarded with try/catch so a broken/read-only DB does not crash the successful API path.

Pattern D — numeric-issue-id → org cache

• src/lib/db/schema.ts — new issue_org_cache SQLite table with schema v14 → v15 migration (issue_id TEXT PK, org_slug TEXT, cached_at INTEGER).
• src/lib/db/issue-org-cache.ts — new module with getCachedIssueOrg, setCachedIssueOrg, clearCachedIssueOrg, clearAllIssueOrgCache. No TTL — issues are owned by one org for life; stale-mapping detection handled via 404 eviction.
• src/commands/issue/utils.ts:
  • Extracted helper fetchIssueByNumericId(id, explicitOrg, cachedOrg) that returns { issue, cacheEvicted }.
  • resolveNumericIssue and resolveShareIssue now:
    1. Prefer explicit org context (resolveOrg — env vars, config defaults, DSN).
    2. Try the cached org next, routing via the regional org-scoped endpoint.
    3. Fall back to the legacy unscoped endpoint otherwise.
    4. On 404 from the cached-org call: evict the entry, retry unscoped, and set cacheEvicted = true so the caller discards the stale slug and re-derives from the permalink (re-caching the correct value). 5xx errors propagate without eviction — transient failures must not forget valid mappings.
    5. After a cold-path permalink extraction, record the numeric-id → org mapping. Cache writes are try/catch-guarded so a broken DB never crashes the successful API path.
• src/lib/db/auth.ts — clearAuth() calls clearAllIssueOrgCache() on logout so mappings don't leak across accounts.

The stale-cache bug (Seer + Cursor Bugbot caught this)

The initial implementation had a subtle bug: when fetchIssueByNumericId internally caught a 404 from the cached-org endpoint, evicted the entry, and fell back to the unscoped endpoint, the caller's local cachedOrg variable still held the stale slug and won the ?? chain over extractOrgFromPermalink(issue.permalink). Downstream calls (events, traces) would then target the wrong org.

Fix: the helper returns { issue, cacheEvicted }; callers gate cachedOrg through effectiveCachedOrg = cacheEvicted ? null : cachedOrg, and re-cache the corrected mapping from the permalink. Regression test in test/commands/issue/utils.test.ts explicitly asserts the returned org is the correct one, not the stale one.

Tests

• test/lib/db/project-cache.test.ts — new tests for getCachedProjectBySlug across all three cache key shapes, MAX-by-cached_at tiebreak, org/project mismatch, and legacy rows with null project_id. Merged into the existing clearProjectCache suite with added getCachedProjectBySlug assertions.
• test/lib/db/issue-org-cache.test.ts — new file with 11 tests covering get/set/clear/clear-all semantics, empty-key no-ops, and isolation from unrelated tables.
• test/lib/resolve-target.test.ts — new tests for fetchProjectId covering cache-hit (no API call), write-back on miss, and fall-through when a cached row has no projectId (legacy schema rows).
• test/commands/issue/utils.test.ts — new describe("Pattern D") block with 4 tests:
  • Warm cache → single org-scoped call, no legacy fallback.
  • Stale-cache fix: 404 on cached org → helper evicts, falls back, and returns the correct permalink-derived org (NOT the stale slug).
  • Cold path → legacy fallback populates the cache for next time.
  • 5xx on cached-org call propagates without evicting the cache (transient failure protection).
• test/lib/db/auth.test.ts — new integration test asserting clearAuth() drops issue_org_cache entries.

All tests green locally: 5106 unit + 138 isolated + 171 on impacted files. Typecheck clean, lint clean (only pre-existing unrelated warning in markdown.ts).

Archived Sentry issues (non-actionable Consecutive HTTP)

For reference, these were marked archived_forever as part of this triage:

• Pattern A (issue → event → trace data dependency): CLI-12C, CLI-1BB, CLI-168, CLI-11C, CLI-SN, CLI-AQ
• Pattern B (issue-events cursor pagination): CLI-1B0, CLI-1B1, CLI-1B2
• Pattern C pagination (issues cursor): CLI-TA
• Pattern D cold-cache (org discovery fan-out, already cached on warm path): CLI-19S, CLI-19W

Why not leverage the existing HTTP response cache for the issue-id → org mapping?

(Short answer: different lookup direction + TTL mismatch.)

The HTTP response cache (createAuthenticatedFetch + http-cache-semantics) keys by request URL. It answers "what was the body of GET /issues/123/ last time?", not "which org owns issue 123?" — the org is derived from the response body's permalink, not from any URL the cache could index. Even if we could answer that, the HTTP cache honors server TTLs (60s–5min for Sentry's typical GET responses), whereas the issue→org mapping is effectively permanent for an issue's lifetime. And crucially: relying on the HTTP cache still requires firing the unscoped endpoint at least once per session, which is the exact call the issue_org_cache lookup skips. The two caches compose orthogonally — HTTP cache speeds up repeat identical requests; issue_org_cache eliminates the need for the unscoped request at all on warm runs.